Oslo Båtutleie er et nystartet firma som spesialiserer seg på utleie av seilskuter og større motorbåter. Kundegruppen består i hovedsak av firma og organisasjoner som skal på gruppeturer (for eksempel firmafester og events). De blir også kjørt sightseeing i perioder. Privatpersoner har også mulighet til å bestille turer og dette er populært, for eksempel til bryllupsfest eller lignende.

I oppstartsfasen har firmaet basert seg på bruk av programmene i Microsoft Office-pakken til å organisere den daglige driften. De ansattes arbeidsoppgaver, kort oppsummert, dreier seg om mail og telefonkorrespondanse med kunder og leverandører, oppdatering av kundeinformasjon, utforming av tilbud og leieavtaler samt oppretting av bookinger. I tillegg til dette har daglig leder ansvar for oppretting av arbeidsavtaler, vedlikehold av ansattlister samt kjøring av lønninger og generelt regnskap for bedriften. Bedriften benytter et eget regnskap og økonomisystem.

Bedriften bruker Microsoft Word til å skrive kontrakter og tilbud, Excel til ansattlister og oversikt over båter og priser. Til lagring av kundeinformasjon og epost benyttes Outlook. Kalenderfunksjonen i samme program benyttes også til å plotte inn båtbookinger. Hver båt har sin egen kalender.

Fakturaer må legges manuelt inn i bedriftens økonomisystem.

Etter hvert som driften har eskalert har overnevnte løsning vist seg å være lite oversiktlig og tungvint, og dette har skapt mye problemer i det daglige arbeidet:

· Bedriftens IT-ansvarlig estimerer at han på ukentlig basis bruker opp til 25 timer på å hjelpe til med problemer som oppstår i forbindelse med utføring av ordinære arbeidsoppgaver.

· De ansatte føler selv at de bruker uforholdsmessig mye tid på datautfordringer, og at dette går ut over service over for bedriftens kunder.

· Det har også blitt en betydelig mengde feilbookinger grunnet at informasjon må bli manuelt overført mellom de forskjellige programmene, og blant annet dette har ført til at andelen misfornøyde kunder i første driftshalvår har klatret til 25% (av antall bookinger), ut i fra undersøkelser bedriften har gjort.

Oslo Båtutleie har på bakgrunn av dette besluttet å anskaffe et system som er skreddersydd bedriftens bruksområder. Bedriften ønsker at alle oppgavene som nevnt over skal kunne utføres ved hjelp av et enhetlig system, med unntak av det som faller inn under økonomisystemets område.

1.2 mål

Prosjektets mål er å skreddersy et datasystem tilpasset Oslo Båtservice’s behov i den daglige driften. Datasystemet skal være en enhetlig applikasjon som erstatter alle de separate programmene som bedriften per dags dato er avhengig av. Dette dreier seg om programvare for tekstredigering, regneark, kalender, Epost, kontakter.

Systemet skal effektivisere hverdagen for de ansatte, få ned feilprosenten knyttet til registrering av data, og sørge for mer fornøyde kunder:

· Tiden IT-ansvarlig bruker på å assistere de ansatte med problemløsing på ukentlig basis skal reduseres med 50% innen 3 måneder etter at systemet er satt i drift.

· Tiden de ansatte bruker på tungvint arbeidsflyt og datatekniske problemer på ukentlig basis skal reduseres med 30% innen 3 måneder etter at systemet er satt i drift.

· Antall feilregistreringer av data forårsaket av ansatte skal reduseres med 90% innen 3 måneder etter at systemet er satt i drift.

· Andelen misfornøyde kunder på grunn av feil forårsaket av dataproblemer skal reduseres med 85% innen 3 måneder etter at systemet er satt i drift.

Tidsaspekt.

Ferdig produkt i henhold til omfang (kap. 1.3) skal være klart innen 25. November 2011

1.3 omfang

Vi vil innledningsvis gjennomføre en kravanalyse for å kartlegge kundens behov til funksjonalitet i systemet. Dette vil gjennomføres ved diskusjon innad i gruppen for å forsøke å tilegne oss en god forståelse av oppdragsgivers domene, samt å prøve å sette oss inn i arbeidssituasjonen til de ansatte.

På grunnlag av kravanalysen vil vi utvikle en kravspesifikasjon som lister opp funksjonelle og ikke-funksjonelle krav til systemet. Kravspesifikasjonen vil danne grunnlag for et forslag til løsning som presenteres for kunden. Ut i fra kundens tilbakemeldinger til forslaget vil dette enten bli satt i utvikling, eller bli endret dersom dette er nødvendig.

Løsningen vil bli utviklet og dokumentert i en prosjektrapport, men vil ikke bli implementert i dette prosjektet. Det vil altså ikke foreligge programkode ved ferdigstilt prosjekt. Unntaket er pseudokode, som antakelig vil benyttes for å demonstrere ulike funksjoner.

1.4 Antagelser og begrensninger

Følgende antagelser og begrensninger er gjort for arbeidet i prosjektet:

Antagelser:

Vi antar at oppdragsgiver har nødvendig maskinvare og infrastruktur tilgjengelig til å kjøre løsningen. Dette innebærer PC-er til de ansatte som skal bruke systemet, server til å kjøre web-server og database med tilfredsstillende backup-løsning, samt lokalt nettverk og ordinær internett-tilknytning.
Vi arbeider mot en fiktiv kunde. Uthenting av krav er dermed gjort ved diskusjon i gruppen, der vi har prøvd å sette oss så godt som mulig inn i domenet og arbeidssituasjonen til brukerne i vår tenkte bedrift.

Begrensninger:

Løsningen vil ikke bli implementert (ingen programmering)
Vår hovedprioritet er å utvikle og få frem funksjonaliteten i de deler av systemet som brukeren vil jobbe direkte mot i det daglige.
Database-tilknytning er noe nedprioritert av tidsmessige årsaker og vil ikke detaljeres i stor grad
Tilknytning til eksternt regnskap/økonomisystem blir ikke vektlagt.

1.5 utviklingsmodell

Vi skal i prosjektet benytte utviklingsmodellen Unified Process (UP). Denne modellen består av fire faser: idéfasen, utdypningsfasen, konstruksjonsfasen, og overgangsfasen.

I motsetning til den tradisjonelle fossefallsmetoden gir UP oss muligheten til å kunne gå bakover i prosjektet og evaluere hva vi har gjort tidligere og om nødvendig gjøre forbedringer. Dette er hensiktsmessig da man ofte får en bedre og bedre forståelse av problemstilling etter hvert som man jobber seg nedover i et prosjekt. Man vil da ofte se nødvendigheten av å endre på løsninger man tidligere har designet. Det er også stor sjanse for at kravene til løsning forandrer seg underveis. UP er iterativ og lar oss utvikle løsninger et steg om gangen, for så å kunne gå tilbake å revurdere og forfine det vi allerede har gjort. Fasene deles i UP opp i iterasjoner, som er hovedsakelig tidsdefinerte luker der man jobber med definerte oppgaver. Iterasjonen avsluttes med at man analyserer og vurderer arbeidet som har blitt gjort, som igjen gir grunnlag for arbeidet som skal utføres i neste iterasjon.

Under er en illustrasjon som viser en typisk fordeling av aktiviteter over de forskjellige fasene og iterasjonene:

Description: Development-iterative

Figur 1.5.0 Kilde: Wikipedia - http://en.wikipedia.org/wiki/Unified_Process (23.09.2011)

Her følger litt informasjon om hvordan vi har tilpasset UP i vårt prosjekt.

Da løsningen i dette tilfelle ikke skal implementeres er det derfor hensiktsmessig for oss å fokusere på de tre første fasene, altså idéfasen, utdypningsfasen og konstruksjonsfasen. UP inneholder mange disipliner; forretningsmodellering, krav, analyse, design, implementasjon, testing og idriftsettelse. Igjen velger vi å fokusere på et utvalg av disse disiplinene, og begrunnelsen for dette er igjen at vi ikke skal implementere løsningen i dette prosjektet. Vi holder oss derfor til disiplinene forretningsmodellering, krav, analyse og design. Da det i prosjektet ikke er lagt større vekt på lønnsomhetsvurderinger og liknende omformulerer vi disiplinene litt og sitter igjen med planlegging, krav & analyse/design:

Planlegging: Denne disiplinen består i stor grad av innledende runder med idéstorming, finne ut hva prosjektet skal omhandle og definere en problemstilling å jobbe ut i fra. I tillegg må vi få på plass brikkene i prosjektarbeidet. Vi fordeler ansvar og jobber med å få i gang og oppdatere styringsdokumenter og rammene for prosjektet vårt. Den tyngste jobben blir gjort innledningsvis i prosjektet, men det må planlegging til underveis i prosjektet, for eksempel i forkant av nye iterasjoner.

Krav: Ut i fra prosjektets problemstilling henter vi ut de nødvendige krav til løsningen vi skal tilby kunden. Vi gjør dette ved å forsøke å forstå kundens domene, samt sette oss inn i arbeidssituasjonen til de ansatte i firmaet. Vi bruker Use Case som et viktig verktøy for å hente ut krav i denne disiplinen. Dette vil resultere i en kravspesifikasjon. Mye av arbeidet i denne disiplinen blir gjort innledningsvis, men krav til løsning vil gjerne endres underveis, og vi vil antakeligvis få en dypere forståelse av problemområdet etter hvert som vi jobber, og dermed vil denne disiplinen være tilstedeværende gjennom hele prosjektet.

Analyse/design: I denne disiplinen jobber vi ut i fra kravene vi har tilgjengelig og forsøker å forme et system ut i fra dette. Arbeidet omfatter modellering, og vi vil produsere utdypet Use Case-modell, domenemodell, aktivitetsdiagram, sekvensdiagram, samt utarbeide brukergrensesnitt for løsningen. Dette vil ligge til grunnlag for senere konstruksjon av løsningen.

Vi har planlagt en iterasjon i idéfasen, to iterasjoner i fordypningsfasen og to iterasjoner i konstruksjonsfasen. Vi setter av ca. 2 uker per iterasjon, med unntak av iterasjon 1, som er ca. 4 uker.

Beskrivelse av iterasjoner i prosjektet:

Figur 1.5.1

Iterasjon 1:

Planlegging
Overordnet Use Case
Overordnet Kravspesifikasjon
Kvalitetssikring
Evaluering

Iterasjon 2:

Re-planlegging
Detaljert Use Case
Detaljert kravspesifikasjon
Overordnet analyse
Kvalitetssikring
Evaluering

Iterasjon 3:

Re-planlegging
Detaljert analyse
Overordnet design
Kvalitetssikring
Evaluering

Iterasjon 4:

Re-planlegging
Detaljert design
Kvalitetssikring
Evaluering

Iterasjon 5:

Detaljert design
Kvalitetssikring
Evaluering

1.6 Suksesskriteria

Hva skal til for at vi lykkes med dette prosjektet?

· Vi må jobbe jevnt med oppgaven hele tiden. Ellers er det lett å komme på etterskudd i forhold til leveringer osv.

· Alle gruppemedlemmene må sette av nok tid til å utføre de oppgavene som er blitt utdelt.

· God prosjektledelse

· God, åpen dialog mellom gruppemedlemmer.

· God dialog med kunden gjennom hele prosjektet.

1.7 Risiko og tiltak

Her er en oversikt over uforutsette ting som kan stoppe/hindre/ødelegge prosjektet eller fremdriften.

Risiko	Sannsynlighet	Konsekvens	Tiltak
Sykdom	Lav	Gruppemedlem kan få problemer med å få fullført sine arbeidsoppgaver	Sette seg inn i andre sitt arbeid, slik at man har mulighet til å overta om nødvendig.
Tidsmangel	Høy	Gruppen kan få problemer med å levere avtalt arbeid til rett tid	Sette tydelige interne frister. Gi beskjed til andre gruppemedlemmer dersom man henger etter, mulighet for å få hjelp
Problemer med bruk av verktøy eller teknikker	Middels	Det kan oppstå forsinkelser som kan føre til tidsmangel og problemer med å holde frister	Arrangere intern workshop i gruppen Følge forelesninger Lese pensum Kontakte veileder / forleser
Tap av data	Lav	Gruppen kan miste verdifullt arbeid, som må gjøres på nytt. Dette kan føre til forsinkelser og tidsmangel	Ta backup hver dag Bruk dropbox
Problemer med å få tak i informasjon og hente ut krav	Middels	Gruppen sitter igjen med svakt grunnlag for analyser og dette kan føre til et produkt som ikke lever opp til kundens forventninger	Sett av nok tid innledningsvis til å forsøke å forstå domenet, og forsøke å sette seg inn i sluttbrukernes arbeidssituasjon.

1.8 rapport-oversikt

Kort oversikt over strukturen i prosjektrapporten:

· Kapittel 1: Informasjon om prosjektoppgaven.

· Kapittel 2: Informasjon om utviklingsmodellen

· Kapittel 3: Kravanalyse (kravspesifikasjon, Use Case m.m.)

· Kapittel 4: Design (Modellering, diagram m.m)

· Kapittel 5: Vurdering av løsningen, gruppens arbeid og utviklingsmodellen vi har benyttet

· Kapittel 6: Konklusjon

· Kapittel 7: Litteraturliste

2 beskrivelse av prosjektleveransene

Prosjektet vi jobber med vil produsere en rekke artefakter. Under er en kort beskrivelse av disse:

Use Case – modeller:

Utarbeiding av Use Case –modeller (diagrammer + tekstlige beskrivelser) er en viktig metode for å hente ut krav til systemet vi skal designe. Vi skal levere detaljerte Use Case-modeller, med tekstlig beskrivelse av essensielle funksjoner i systemet.

Kravspesifikasjon:

Prosjektet omfatter en analyse-del som dreier seg om å få tak i de funksjonene systemet skal oppfylle. Dette gjøres ved å gjøre en kravanalyse, utarbeide Use Case-modeller og på grunnlag av dette lage en kravspesifikasjon for systemet.

Kravspesifikasjonen skal inneholde et sett med funksjonelle krav og et sett med ikke-funksjonelle krav til løsningen.

Domenemodell:

Vi skal lage en domenemodell for løsningen. Denne modellen visualiserer konsepter i den virkelige verden, og forholdet dem i mellom. Modellen sikrer oss forståelse av hvordan ”ting” samspiller i bedriften vi jobber mot, altså får vi en bedre forståelse av domenet.

Aktivitetsdiagram:

Vi ønsker å nærme oss løsninger og ikke bare konstatere krav. Aktivitetsdiagrammet tar et brukstilfelle (fra Use Case) og ser på aktiviteter som må til for å oppfylle dette. Vi skal lage et aktivitetsdiagram som viser hovedflyten i systemet.

Klassediagram:

Klassediagrammet viser elementene/objektene i systemet og hvordan disse henger sammen med hverandre. Vi skal lage et klassediagram som viser hovedelementene i vårt system og samspillet mellom disse (f.eks metodekall, som hentet ut fra sekvensdiagram)

Sekvensdiagram:

Sekvensdiagrammet brukes til å vise atferden til forskjellige objekter innen et brukstilfelle. Vi ser hvordan ulike objekter kommuniserer med hverandre.

Forslag til logisk arkitektur:

På grunnlag av vår analyse vil vi komme med et forslag til logisk arkitektur som kan brukes på løsningen vi utvikler.

Forslag til brukergrensesnitt:

Her vil vi presentere et forslag til brukergrensesnitt tilpasset løsningen vi har utarbeidet.

Vurdering:

Her vurderer vi vår egen innsats, løsningen vi har foreslått samt utviklingsmodellen vi har benyttet.

Konklusjon:

Vi oppsummerer hovedpunktene i arbeidet. Har vi oppnådd målsetningen med prosjektet og er det ting som burde vært gjort annerledes?

Leveranse 1 – 23.09.2011:

· Levering av komplett prosjektplan (v.1.0) - inkluderer blant annet bakgrunn, målformulering, omfang, informasjon om utviklingsmodell, prosjektoversikt og prosjektplan

· Hjemmeside for gruppen

Leveranse 2 – 12.10.2011:

· Levering av prosjektrapport (v.0.3) med utfylt kap 1-3, med overordnet kravspesifisering og Use Case-modellering.

· Oppdatert hjemmeside

· Oppdatert prosjektplan

Leveranse 3 – 04.11.2011: Levering av prosjektrapport (v.0.6) med utfylt kap 1-4, modellering.

Leveranse 4 – 25.11.2011: Levering av prosjektrapport (v.1.0). Ferdig prosjekt – kvalitetssikring.

3 prosjektorganisasjon og plan

3.1 prosjektorganisasjon

Vi har en gruppe bestående av fire personer. Vi har en prosjektleder i gruppen. Prosjektleder har det overordnede ansvar for kvalitetssikring av alt arbeid som utføres, og sørger for jevn fordeling av arbeid innad i gruppen. Gruppen er basert på gjensidig respekt mellom medlemmene. Alle skal bli hørt, og vi skal ha en god tone i gruppen til en hver tid. Uoverensstemmelser skal avgjøres ved avstemning, Prosjektleder har ikke vetorett, men kan avgjøre dersom ”uavgjort” i avstemning.

Description: Prosjektorganisering-diagram

Figur 3.1

3.2 roller og ansvar

Rolle	Ansvar	Navn	Kompetanse	Tidsperiode
Prosjektleder	Organisering av ressurser Kvalitetssikring Backup Planer og rapporter	Espen Mjølund	Student anvendt datateknologi	Aug-11 – Nov-11
Prosjektmedarbeider	Webside Use Case-modeller Brukergrensesnitt	Robert Bicanic Bache	Student anvendt datateknologi	Aug-11 – Nov-11
Prosjektmedarbeider	Kravanalyse Kravspesifikasjon Designmodellering	Marius Kværner Karlsen	Student anvendt datateknologi	Aug-11 – Nov-11
Prosjektmedarbeider	Designmodellering Styringsdokumenter Fortløpende dokumentasjon	Jonas Bjørnerud	Student anvendt datateknologi	Aug-11 – Nov-11

3.3 milepæler og aktiviteter

· Milepæl 1: 23.09.2011

o Aktiviteter:

· Registrering av gruppe hos foreleser

· Hjemmesideutvikling

· Tema for prosjektet

· Prosjektplan versjon 1.0

o Leveranse(r):

· Leveranse 1:

· Prosjektplan versjon 1.0

· Hjemmeside

· Milepæl 2: 12.10.2011

o Aktiviteter:

· Kravanalyse (Innledende)

· Overordnet kravspesifikasjon

· Innledende Use Case-modell

· Prosjektrapport kapittel 1-2, samt 3.1-3.2 (versjon 0.3)

· Prosjektplan (revidert)

· Nettside (revidert)

o Leveranse(r):

· Leveranse 2:

· Prosjektrapport versjon 0.3

· Prosjektplan versjon 1.1

· Hjemmeside (revidert)

· Milepæl 3: 04.11.2011

o Aktiviteter:

· Detaljert kravspesifikasjon

· Detaljert Use Case-modell

· Domenemodell

· Aktivitetsdiagram

· Klassediagram

· Sekvensdiagram

· Logisk arkitektur

· Brukergrensesnitt

· Prosjektrapport kapittel 1-4 (versjon 0.6)

· Prosjektplan (revidert)

· Nettside (revidert)

o Leveranse(r):

· Leveranse 3:

· Prosjektrapport versjon 0.6

· Nettside (revidert)

· Milepæl 4: 25.11.2011

o Aktiviteter:

· Domenemodell

· Aktivitetsdiagram

· Klassediagram

· Sekvensdiagram

· Logisk arkitektur

· Brukergrensesnitt

· Kvalitetssikring

· Evaluering av prosjekt

· Konklusjon

· Presentasjon

· Prosjektrapport (versjon 1.0)

· Prosjektplan (revidert)

· Nettside (revidert)

o Leveranse(r):

· Leveranse 4:

· Prosjektrapport versjon 1.0

· Nettside (revidert)

3.4 oversikt prosjekt plan

Her følger et Gantt-diagram over prosjektets forløp. Vi henviser til prosjektets nettsted for en mer høyoppløselig versjon av diagrammet. Her ligger også prosjektfilen som danner grunnlag for diagrammet, dersom det er ønskelig å se råmaterialet.

Description: Macintosh HD:Users:em:Desktop:Prosjektoppgave Systemutvikling.pdf

Figur 3.4

3.5 arbeidsmåte (”way of working”)

Gruppen har to faste møter hver uke i skolens lokaler. Hvert møte er av ca. to timers varighet. Her vil vi diskutere prosjektets progresjon, og utføre oppgaver som må gjøres i fellesskap.

Utover dette utfører hvert medlem av gruppen individuelle arbeidsoppgaver som klareres på ukentlig basis.

I tillegg har vi ekstramøter når vi føler behov for dette.

3.6 prosjekthjelpemidler

Følgende verktøy og hjelpemidler vil bli brukt i prosjektet:

· Dropbox – Gruppen har vår felles arbeidsmappe i dropbox.

· TeamViewer – Skjermdeling mellom gruppens medlemmer blant annet i forbindelse med gruppemøter.

· Merlin PM – Projektstyringsprogram for Mac. Tilbyr blant annet Gannt-diagrammer og arbeidsfordeling….

· OmniGraffle – Fantastisk program for Mac. Kan brukes til det meste av diagrammer og annet grafikkrelatert. Vi bruker dette blant annet til Use Case-modellering og klasse-diagrammer.

· Microsoft Office – Rapportskriving og presentasjoner

· Skype – Videokonferanse, filoverføring, chat

4 Kostnader

Her er et overslag over kostnader i prosjektet, per fase, og for hele prosjektet.

Timepriser:

Prosjektleder: 320 kr

Prosjektmedarbeider: 270 kr.

Vi estimerer at hver prosjektmedarbeider jobber 4 timer individuelt per uke, og deltar på felles møter på totalt 4 timer per uke. Dette totalt 8 timer på prosjektet per uke per prosjektmedarbeider.

Vi antar at prosjektleder jobber 2 timer mer individuelt per uke enn sine medarbeidere, altså 10 timer totalt.

Ukentlig kostnad for å ha teamet på jobb blir som følger:

Prosjektleder: 320 kr x 10 timer = 3.200 kr

Prosjektmedarbeidere: 270 kr x 8 timer x 3 personer = 6.480 kr

Total (uke)= 9.680 kr

Fase 1 – idéfasen. Varighet: 4 uker. Pris: 9680 kr x 4 = 38.720 kr

Fase 2 – utdypningsfasen. Varighet: 9 uker. Pris: 9680 kr x 9 = 19.360 kr

Fase 3 – konstruksjonsfasen. Varighet: 7 uker. Pris 9680 kr x 7 = 67.760 kr

Total pris estimert for hele prosjektet: 125.840 kr

5 admin

5.1 rapportering og møter

Vi har faste møter to ganger i uken, mandag og onsdag. Begge dager i tidsrommet 10.30 – 12.30.

Utover dette arrangerer vi møter ved behov.

Det føres møtereferat fra hvert møte, dette er tilgjengelig på gruppens hjemmeside.

5.2 dokumenthåndtering

Gruppen har et felles arbeidsområde for alle relaterte dokumenter i Dropbox. På denne måten kan alle holde en viss oversikt over hva de andre jobber med og det er lettere å samarbeide om en oppgave om nødvendig.

Dokumenter av relevans til prosjektet vil legges ut til nedlasting på gruppens nettsted i forbindelse med hver del-leveranse.

5.3 timeregistrering

Her følger oversikt, uke for uke over timeforbruk for alle gruppemedlemmene.

Ukenummer:	Espen	Robert	Marius	Jonas
Total idéfase:	18 timer	13 timer	7 timer	7 timer
Total fordypningsfase:
Total konstruksjonsfase:
Total for prosjekt:

5.4 informasjon

Prosjektets nettsted finnes på følgende adresse: http://www.stud.hio.no/~s168499/sysutv_H10/index.php

Her finnes styringsdokumenter, møtereferat, diagrammer og andre dokumenter relatert til prosjektet.

6 referanser

Kilder:

Illustrasjon 1.5.0: Kilde: Wikipedia - http://en.wikipedia.org/wiki/Unified_Process (23.09.2011)